.releaserc.json (1)

18-18: Consider aligning breaking-change policy with Semantic Versioning.

Line 18 maps breaking changes to minor releases, which contradicts semantic-release defaults and standard SemVer practice requiring major for breaking changes. This can hide compatibility breaks from consumers. Either document this as intentional policy (e.g., for pre-1.0 development) or align with SemVer:

SemVer-aligned alternative

-          { "breaking": true, "release": "minor" }
+          { "breaking": true, "release": "major" }

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In @.releaserc.json at line 18, Update the .releaserc.json entry that maps
breaking changes (the object with "breaking": true and "release": "minor") to
follow SemVer by changing its "release" value from "minor" to "major", or
alternatively add a comment/README note in the repo explaining this is an
intentional deviation (e.g., pre-1.0 policy) so reviewers know it’s deliberate;
locate the object matching "breaking": true to apply the change.

scripts/discord-scaffold.mjs (1)

124-125: Rename the map key to match updated role semantics.

roles.nodeOperator now stores "Node Runner", which is misleading for future maintenance.

Small naming cleanup

-  roles.nodeOperator = await upsertRole(existing, {
+  roles.nodeRunner = await upsertRole(existing, {
     name: "Node Runner",

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@scripts/discord-scaffold.mjs` around lines 124 - 125, The map key
roles.nodeOperator is misleading because upsertRole(existing, { name: "Node
Runner", ... }) actually stores the "Node Runner" role; rename the key to
roles.nodeRunner (and update every reference to roles.nodeOperator) so the
variable name matches the role semantics, and update any usages (reads/writes)
that reference roles.nodeOperator to use roles.nodeRunner; ensure the
upsertRole(...) call and any role checks or permissions logic (e.g., role
comparisons) are updated accordingly.

packages/marketplace/src/marketplace.test.ts (1)

66-72: Add an explicit treasury assertion in rounding test.

Line 67 documents treasury=17, but Line 72 checks it only implicitly through sum. A direct assertion would make regressions easier to pinpoint.

Diff

   it("treasury absorbs rounding (not validator)", () => {
     // 99 cents: node=69, dev=9, validator=4, treasury=remainder=17
     const r = calcExecutionRevenue(99);
     expect(r.nodeCents).toBe(69);
     expect(r.developerCents).toBe(9);
     expect(r.validatorCents).toBe(4);
+    expect(r.treasuryCents).toBe(17);
     expect(r.nodeCents + r.developerCents + r.treasuryCents + r.validatorCents).toBe(99);
   });

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@packages/marketplace/src/marketplace.test.ts` around lines 66 - 72, The test
for rounding in the marketplace suite documents treasury=17 but only asserts the
total sum; update the test that calls calcExecutionRevenue(99) in
marketplace.test.ts to add a direct expectation for r.treasuryCents toBe(17) so
the treasury rounding is checked explicitly alongside r.nodeCents,
r.developerCents, and r.validatorCents.

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

programs/settlement/src/instructions/init_node_vault.rs (1)

29-44: ⚠️ Potential issue | 🔴 Critical

Critical: Validate usdc_mint against canonical USDC to prevent bricking settlement.

The usdc_mint account is fully caller-controlled. Since this PDA is initialized only once, a malicious or mistaken first caller can create the vault against any mint. All subsequent add_earnings/settle_earnings calls would then fail or be forced to use that incorrect mint, effectively bricking USDC settlement for the node.

Proposed fix: Add canonical USDC validation

Option 1: Add a runtime check in the handler:

+use crate::errors::SettlementError;
+
+// Canonical USDC mints
+pub const USDC_MINT_DEVNET: &str = "4zMMC9srt5Ri5X14GAgXhaHii3GnPAEERYPJgZJDncDU";
+pub const USDC_MINT_MAINNET: &str = "EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v";

 pub fn handler(ctx: Context<InitNodeVault>, _args: InitNodeVaultArgs) -> Result<()> {
+    // Validate usdc_mint is canonical USDC (devnet or mainnet)
+    let mint_key = ctx.accounts.usdc_mint.key().to_string();
+    require!(
+        mint_key == USDC_MINT_DEVNET || mint_key == USDC_MINT_MAINNET,
+        SettlementError::InvalidUsdcMint
+    );
+
     // The account is fully initialised by the #[account(init)] constraint.

Option 2: Store canonical USDC mint in SettlementConfig and validate against it:

 #[derive(Accounts)]
 #[instruction(args: InitNodeVaultArgs)]
 pub struct InitNodeVault<'info> {
+    /// Global config — contains canonical USDC mint for this cluster.
+    #[account(
+        seeds = [SettlementConfig::SEED],
+        bump = config.bump,
+    )]
+    pub config: Account<'info, SettlementConfig>,
+
     /// USDC mint — must match config.usdc_mint.
-    pub usdc_mint: Account<'info, Mint>,
+    #[account(
+        constraint = usdc_mint.key() == config.usdc_mint @ SettlementError::InvalidUsdcMint
+    )]
+    pub usdc_mint: Account<'info, Mint>,

Option 2 is preferred as it keeps the canonical mint configurable per-cluster via initialize_config.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@programs/settlement/src/instructions/init_node_vault.rs` around lines 29 -
44, The vault init currently accepts a caller-provided usdc_mint allowing a
malicious first initializer to bind the vault to a wrong mint; add validation to
ensure the mint equals the canonical USDC mint stored in your config: extend
SettlementConfig to include a canonical_usdc_mint field (set via
initialize_config), then in the init_node_vault handler check that the provided
usdc_mint.key() matches SettlementConfig::canonical_usdc_mint and return an
error if not; update any callers/tests to supply the canonical mint and keep
add_earnings/settle_earnings behavior unchanged but now safe because
vault/usdc_mint are validated.

scripts/setup-mach-token.ts (3)

67-73: ⚠️ Potential issue | 🟠 Major

Read SOLANA_WALLET_PATH and expand tilde paths.

The .env.example advertises SOLANA_WALLET_PATH, but this script only checks ANCHOR_WALLET. Paths like ~/.config/solana/id.json won't expand correctly in Node.js.

Proposed fix

 function loadKeypair(): Keypair {
-  const walletPath =
-    process.env.ANCHOR_WALLET ?? path.join(os.homedir(), ".config", "solana", "id.json");
+  const configuredPath =
+    process.env.ANCHOR_WALLET ??
+    process.env.SOLANA_WALLET_PATH ??
+    path.join(os.homedir(), ".config", "solana", "id.json");
+  
+  const walletPath = configuredPath.startsWith("~/")
+    ? path.join(os.homedir(), configuredPath.slice(2))
+    : configuredPath;
+
   const raw = fs.readFileSync(walletPath, "utf-8");
   const bytes = JSON.parse(raw) as number[];
   return Keypair.fromSecretKey(Uint8Array.from(bytes));
 }

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@scripts/setup-mach-token.ts` around lines 67 - 73, The loadKeypair function
currently only reads ANCHOR_WALLET and doesn't expand tilde paths; update
loadKeypair to prefer SOLANA_WALLET_PATH (fall back to ANCHOR_WALLET then the
existing default), and ensure any path starting with "~" is expanded to the user
home directory (e.g., replace leading "~" with os.homedir()) before passing to
fs.readFileSync/Path APIs so "~/.config/solana/id.json" resolves correctly; keep
the rest of the logic (JSON parse and Keypair.fromSecretKey) unchanged.

---

52-65: ⚠️ Potential issue | 🟡 Minor

Add runtime validation for SOLANA_CLUSTER.

The CLUSTER variable accepts any string at runtime. Invalid values like "testnet" or "staging" will silently fall through to devnet URLs in getRpcUrl(). The code also supports "localnet" (line 55) which isn't documented.

Proposed fix

-const CLUSTER = process.env.SOLANA_CLUSTER ?? "devnet";
+function parseCluster(): "devnet" | "mainnet-beta" | "localnet" {
+  const value = (process.env.SOLANA_CLUSTER ?? "devnet").trim();
+  if (value !== "devnet" && value !== "mainnet-beta" && value !== "localnet") {
+    throw new Error(`Invalid SOLANA_CLUSTER: ${value}. Must be "devnet", "mainnet-beta", or "localnet".`);
+  }
+  return value;
+}
+
+const CLUSTER = parseCluster();

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@scripts/setup-mach-token.ts` around lines 52 - 65, The CLUSTER value (from
SOLANA_CLUSTER) is not validated and can silently map unknown strings to devnet;
update getRpcUrl (or the initialization of CLUSTER) to validate the environment
value against an explicit allowed set (e.g., "localnet", "devnet",
"mainnet-beta"), and if the value is invalid either throw an Error or log a
clear message and exit so misconfigured deployments fail fast; make sure to
reference CLUSTER and getRpcUrl in the message and state the supported values so
callers know the valid options.

---

172-176: ⚠️ Potential issue | 🟡 Minor

Make explorer link and .env hints dynamic based on CLUSTER.

The explorer URL and .env guidance are hardcoded to devnet. When running with CLUSTER=mainnet-beta, this creates a misleading user experience.

Proposed fix

-  console.log(`  Explorer:  https://explorer.solana.com/address/${mintAddress}?cluster=devnet`);
+  const explorerSuffix = CLUSTER === "mainnet-beta" ? "" : `?cluster=${CLUSTER}`;
+  console.log(`  Explorer:  https://explorer.solana.com/address/${mintAddress}${explorerSuffix}`);
   console.log("\nAdd to .env:");
   console.log(`  MACH_MINT_ADDRESS=${mintAddress}`);
-  console.log("  SOLANA_CLUSTER=devnet");
+  console.log(`  SOLANA_CLUSTER=${CLUSTER}`);

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@scripts/setup-mach-token.ts` around lines 172 - 176, The printed explorer URL
and .env hints are hardcoded to devnet; update the console output to use the
CLUSTER value (read from process.env.CLUSTER or the existing cluster variable)
and fall back to "devnet" if unset, so the Explorer link (constructed with
mintAddress and the cluster query param) and the suggested SOLANA_CLUSTER value
reflect the actual cluster (e.g., "devnet" or "mainnet-beta"); change the three
console.log lines that reference mintAddress and the hardcoded "devnet" to
interpolate the resolved cluster variable instead.

scripts/setup-devnet.ts (2)

28-41: ⚠️ Potential issue | 🟠 Major

Normalize API_BASE_URL to prevent double slashes in webhook URL.

When API_BASE_URL ends with /, the concatenation creates //webhooks/helius, which may break idempotency matching and create duplicate webhooks.

Proposed fix

-  const apiBaseUrl = process.env.API_BASE_URL;
+  const apiBaseUrl = process.env.API_BASE_URL?.replace(/\/+$/, "");
   if (!apiBaseUrl) {
     console.error(
       "API_BASE_URL is not set. Set it to your public API URL (e.g. https://api.maschina.ai)",
     );
     process.exit(1);
   }

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@scripts/setup-devnet.ts` around lines 28 - 41, The webhook URL construction
can produce a double slash when API_BASE_URL ends with a slash; normalize
apiBaseUrl before building webhookUrl by trimming any trailing slash (operate on
the apiBaseUrl variable obtained from process.env.API_BASE_URL) or use a
URL-join approach when composing the webhookUrl variable; update the logic where
const apiBaseUrl is validated and where const webhookUrl =
`${apiBaseUrl}/webhooks/helius` is defined (and keep getHeliusClient() usages
unchanged) so webhookUrl always becomes "<origin>/webhooks/helius" without
duplicated slashes.

---

10-14: ⚠️ Potential issue | 🟡 Minor

Header comment overstates behavior.

Line 11 states the script "Verifies the settlement program is deployed" but no RPC/account check is performed. Either add actual verification or reword the comment.

Proposed fix (update comment)

 * What it does:
-*   1. Verifies the settlement program is deployed at SETTLEMENT_PROGRAM_ID
-*   2. Registers a Helius webhook for settlement events → API_BASE_URL/webhooks/helius
-*   3. Prints the webhook ID — save to .env as HELIUS_WEBHOOK_ID
+*   1. Registers a Helius webhook for settlement events → API_BASE_URL/webhooks/helius
+*   2. Prints the webhook ID — save to .env as HELIUS_WEBHOOK_ID

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@scripts/setup-devnet.ts` around lines 10 - 14, The header comment claims the
script "Verifies the settlement program is deployed at SETTLEMENT_PROGRAM_ID"
but no RPC/account check exists; either remove or reword that claim or implement
an actual verification: locate the SETTLEMENT_PROGRAM_ID constant in
scripts/setup-devnet.ts and either change the header to say the script "assumes
the settlement program is deployed at SETTLEMENT_PROGRAM_ID" or add a
verification step using the Solana Connection (e.g., connection.getAccountInfo
or getProgramAccounts) to check for an account/executable at
SETTLEMENT_PROGRAM_ID and fail/log if missing before proceeding to the Helius
webhook registration and printing of HELIUS_WEBHOOK_ID.

programs/settlement/src/instructions/add_earnings.rs (2)

16-28: ⚠️ Potential issue | 🔴 Critical

run_id still lacks on-chain deduplication—replay vulnerability persists.

The run_id is only emitted in the event (line 118) but not persisted. If the settlement worker retries or replays a run, this instruction:

1. Transfers USDC again from the authority
2. Increments pending_* balances again
3. Bumps run_count again

For real-money settlement, persist a receipt PDA keyed by run_id and reject duplicates before moving funds.

🛡️ Sketch of dedupe approach

Add a receipt account to prevent replay:

/// Ensures this run_id hasn't been processed before.
#[account(
    init,
    payer = authority,
    seeds = [b"earnings_receipt", args.run_id.as_ref()],
    bump,
    space = 8 + 1, // discriminator + processed flag
)]
pub receipt: Account<'info, EarningsReceipt>,

If the receipt already exists, Anchor's init constraint will fail with AccountAlreadyInUse, providing automatic idempotency.

Also applies to: 116-122

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@programs/settlement/src/instructions/add_earnings.rs` around lines 16 - 28,
The AddEarnings instruction currently only emits run_id in an event and is
vulnerable to replay because run_id is not persisted; add a receipt PDA keyed by
args.run_id to enforce idempotency by rejecting duplicate runs before moving
funds. Modify the AddEarnings handler to require an Account<'info',
EarningsReceipt> (initialized with seeds [b"earnings_receipt",
args.run_id.as_ref()] and payer authority) so Anchor will fail on duplicate
receipts, and check/mark the receipt as processed (EarningsReceipt struct with a
processed flag or just existence) before performing transfers, balance updates,
and bumping run_count.

---

35-48: ⚠️ Potential issue | 🔴 Critical

add_earnings still missing authority validation against SettlementConfig.

Unlike settle_earnings which validates authority.key() == config.authority, this instruction accepts any signer. This allows arbitrary callers to fund the vault and manipulate pending_* balances, potentially inflating payouts or emitting fraudulent EarningsRecorded events.

Add a config account and constrain the authority:

🔒 Proposed fix

 #[derive(Accounts)]
 #[instruction(args: AddEarningsArgs)]
 pub struct AddEarnings<'info> {
-    /// Settlement authority (Maschina multisig) — signs and funds the transfer.
-    #[account(mut)]
+    /// Settlement authority — must match config.authority.
+    #[account(
+        mut,
+        constraint = authority.key() == config.authority @ SettlementError::UnauthorisedSettlement,
+    )]
     pub authority: Signer<'info>,
+
+    /// Global settlement config — holds the trusted authority key.
+    #[account(
+        seeds = [SettlementConfig::SEED],
+        bump = config.bump,
+    )]
+    pub config: Account<'info, SettlementConfig>,

This requires importing SettlementConfig in line 5.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@programs/settlement/src/instructions/add_earnings.rs` around lines 35 - 48,
The add_earnings instruction is missing validation that the signer `authority`
matches the configured multisig; add a `config: Account<'info,
SettlementConfig>` to the instruction context and enforce the constraint that
`config.authority == authority.key()` (mirroring settle_earnings). Update the
account attributes for `config` to be read-only (or as required) and adjust the
handler to use `config` instead of accepting any signer; also import
`SettlementConfig` at the top of the file so the type is available. Ensure
existing logic that updates `pending_*` and emits `EarningsRecorded` remains
unchanged but now only executes when `authority` is validated against `config`.

programs/settlement/src/instructions/initialize_config.rs (2)

3-3: Remove unused import.

SettlementError is imported but not used in this file.

Proposed fix

 use anchor_lang::prelude::*;

-use crate::errors::SettlementError;
 use crate::state::SettlementConfig;

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@programs/settlement/src/instructions/initialize_config.rs` at line 3, The
import SettlementError is unused in this file; remove the use stmt referencing
SettlementError (the line "use crate::errors::SettlementError;") from
initialize_config.rs so only actually used imports remain (verify functions like
initialize_config or structs referenced in the file still compile and remove any
other stale imports if flagged by the compiler).

---

41-48: Consider validating that payout pubkeys are not the default/system program.

Accidentally passing Pubkey::default() or the system program ID for treasury/developer/validators keys would brick settlement. A simple validation could prevent misconfiguration.

Proposed validation

 pub fn handler(ctx: Context<InitializeConfig>, args: InitializeConfigArgs) -> Result<()> {
+    // Sanity check: payout keys should not be default or system program
+    require!(
+        args.treasury_key != Pubkey::default() && args.treasury_key != System::id(),
+        SettlementError::InvalidPayoutKey
+    );
+    require!(
+        args.developer_key != Pubkey::default() && args.developer_key != System::id(),
+        SettlementError::InvalidPayoutKey
+    );
+    require!(
+        args.validators_key != Pubkey::default() && args.validators_key != System::id(),
+        SettlementError::InvalidPayoutKey
+    );
+
     let config = &mut ctx.accounts.config;

This would require keeping the SettlementError import and adding InvalidPayoutKey to the error enum.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@programs/settlement/src/instructions/initialize_config.rs` around lines 41 -
48, In handler (fn handler(ctx: Context<InitializeConfig>, args:
InitializeConfigArgs)) add validations that args.treasury_key,
args.developer_key, and args.validators_key are not Pubkey::default() and not
equal to solana_program::system_program::ID; if any are invalid return
Err(SettlementError::InvalidPayoutKey.into()). Keep existing assignments to
config.authority and config.bump but perform these checks before setting
config.* fields; ensure the SettlementError enum includes InvalidPayoutKey and
that the SettlementError import is retained.

scripts/setup-realms.ts (1)

61-82: Extract shared utilities to reduce duplication.

CLUSTER, getRpcUrl(), and loadKeypair() are duplicated from setup-mach-token.ts with identical logic. This also inherits the same issues: no runtime validation for CLUSTER, no SOLANA_WALLET_PATH support, and no tilde expansion.

Consider extracting these to a shared module (e.g., scripts/lib/config.ts) to fix bugs in one place and maintain consistency.

Example shared module

// scripts/lib/config.ts
import fs from "node:fs";
import os from "node:os";
import path from "node:path";
import { Keypair } from "@solana/web3.js";

export type Cluster = "devnet" | "mainnet-beta" | "localnet";

export function getCluster(): Cluster {
  const value = (process.env.SOLANA_CLUSTER ?? "devnet").trim();
  if (value !== "devnet" && value !== "mainnet-beta" && value !== "localnet") {
    throw new Error(`Invalid SOLANA_CLUSTER: ${value}`);
  }
  return value;
}

export function getRpcUrl(cluster: Cluster = getCluster()): string {
  if (cluster === "localnet") return "http://127.0.0.1:8899";
  const apiKey = process.env.HELIUS_API_KEY;
  if (apiKey) {
    return cluster === "mainnet-beta"
      ? `https://mainnet.helius-rpc.com/?api-key=${apiKey}`
      : `https://devnet.helius-rpc.com/?api-key=${apiKey}`;
  }
  return cluster === "mainnet-beta"
    ? "https://api.mainnet-beta.solana.com"
    : "https://api.devnet.solana.com";
}

export function loadKeypair(): Keypair {
  const configuredPath =
    process.env.ANCHOR_WALLET ??
    process.env.SOLANA_WALLET_PATH ??
    path.join(os.homedir(), ".config", "solana", "id.json");
  
  const walletPath = configuredPath.startsWith("~/")
    ? path.join(os.homedir(), configuredPath.slice(2))
    : configuredPath;

  const raw = fs.readFileSync(walletPath, "utf-8");
  const bytes = JSON.parse(raw) as number[];
  return Keypair.fromSecretKey(Uint8Array.from(bytes));
}

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@scripts/setup-realms.ts` around lines 61 - 82, Extract the duplicated
CLUSTER, getRpcUrl(), and loadKeypair() logic into a shared module (e.g.,
scripts/lib/config.ts) and replace the in-file definitions with imports; in the
shared module implement getCluster() that validates SOLANA_CLUSTER values
("devnet" | "mainnet-beta" | "localnet") and use that in getRpcUrl(cluster) to
preserve existing behavior, update loadKeypair() to prefer SOLANA_WALLET_PATH
then ANCHOR_WALLET, perform tilde (~) expansion for home dir, and throw clear
errors on invalid/missing configs so fixes apply consistently across
setup-realms.ts and setup-mach-token.ts.

scripts/setup-mach-token.ts (1)

117-121: Move constant definitions before usage for clarity.

TYPE_SIZE and LENGTH_SIZE are used at line 117 but defined at lines 179-180. While JavaScript hoisting makes this work, it harms readability.

Proposed fix

Move these constants to the Config section near the top:

 // ─── Config ───────────────────────────────────────────────────────────────────

+// Token-2022 metadata size constants
+const TYPE_SIZE = 2;
+const LENGTH_SIZE = 4;
+
 const MACH_TOKEN = {

And remove them from the bottom of the file.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@scripts/setup-mach-token.ts` around lines 117 - 121, The constants TYPE_SIZE
and LENGTH_SIZE are used when computing metadataExtension and mintLamports but
are defined much later, harming readability; move the constant definitions for
TYPE_SIZE and LENGTH_SIZE up into the Config/top section near other
configuration constants so they are declared before they are referenced
(affecting the computation of metadataExtension, mintLen via
getMintLen([ExtensionType.MetadataPointer]) and the call to
connection.getMinimumBalanceForRentExemption), and remove the duplicate
definitions from the bottom of the file so there’s a single, top-level
declaration.

programs/settlement/src/instructions/settle_earnings.rs (1)

120-122: Verify signer seeds match the pool PDA derivation.

The pool PDA is derived with seeds = [b"pool", args.node_id.as_ref()] (line 43). Here, &args.node_id yields &[u8; 16] which coerces to &[u8], so this is correct. However, for consistency and clarity with the accounts constraint, consider using .as_ref():

-    let pool_seeds: &[&[u8]] = &[b"pool", &args.node_id, &[pool.bump]];
+    let pool_seeds: &[&[u8]] = &[b"pool", args.node_id.as_ref(), &[pool.bump]];

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@programs/settlement/src/instructions/settle_earnings.rs` around lines 120 -
122, The PDA signer seeds in settle_earnings.rs use &args.node_id which works
but should be replaced with args.node_id.as_ref() for clarity and to match the
PDA derivation used elsewhere; update the pool_seeds declaration (and the
signer_seeds usage) to use &[b"pool", args.node_id.as_ref(), &[pool.bump]] so
the seeds and signer_seeds (pool_seeds, signer_seeds) clearly mirror the
original PDA derivation and types.

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

scripts/setup-mach-token.ts (2)

67-70: ⚠️ Potential issue | 🟠 Major

Use SOLANA_WALLET_PATH and expand ~/ before reading keypair file.

The script still ignores SOLANA_WALLET_PATH from .env.example, and Node won’t expand a leading tilde automatically.

Proposed fix

+function resolveWalletPath(): string {
+  const configured =
+    process.env.SOLANA_WALLET_PATH ??
+    process.env.ANCHOR_WALLET ??
+    path.join(os.homedir(), ".config", "solana", "id.json");
+
+  return configured.startsWith("~/")
+    ? path.join(os.homedir(), configured.slice(2))
+    : configured;
+}
+
 function loadKeypair(): Keypair {
-  const walletPath =
-    process.env.ANCHOR_WALLET ?? path.join(os.homedir(), ".config", "solana", "id.json");
+  const walletPath = resolveWalletPath();
   const raw = fs.readFileSync(walletPath, "utf-8");
   const bytes = JSON.parse(raw) as number[];
   return Keypair.fromSecretKey(Uint8Array.from(bytes));
 }

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@scripts/setup-mach-token.ts` around lines 67 - 70, The loadKeypair() function
currently reads walletPath from ANCHOR_WALLET and does not handle
SOLANA_WALLET_PATH or a leading tilde; update loadKeypair() to prefer
process.env.SOLANA_WALLET_PATH if set, and expand a leading "~" to the user's
home directory (e.g., replace a starting "~/" with os.homedir() + "/") before
calling fs.readFileSync so the path resolves correctly on Node.

---

52-65: ⚠️ Potential issue | 🟠 Major

Validate SOLANA_CLUSTER and stop hardcoding devnet in user-facing output.

Invalid cluster values currently fall through and the final explorer/.env output still advertises devnet even when another cluster is used.

Proposed fix

-const CLUSTER = process.env.SOLANA_CLUSTER ?? "devnet";
+function parseCluster(): "devnet" | "mainnet-beta" | "localnet" {
+  const value = (process.env.SOLANA_CLUSTER ?? "devnet").trim();
+  if (value !== "devnet" && value !== "mainnet-beta" && value !== "localnet") {
+    throw new Error(`Invalid SOLANA_CLUSTER: ${value}`);
+  }
+  return value;
+}
+
+const CLUSTER = parseCluster();
@@
-  if (balance < 0.1 * 1e9) {
-    console.error("Insufficient SOL. Run: solana airdrop 2 --url devnet");
+  if (balance < 0.1 * 1e9) {
+    const topUpHint =
+      CLUSTER === "mainnet-beta"
+        ? "Fund this wallet with mainnet SOL."
+        : `Run: solana airdrop 2 --url ${CLUSTER}`;
+    console.error(`Insufficient SOL. ${topUpHint}`);
     process.exit(1);
   }
@@
-  console.log(`  Explorer:  https://explorer.solana.com/address/${mintAddress}?cluster=devnet`);
+  const explorerSuffix = CLUSTER === "mainnet-beta" ? "" : `?cluster=${CLUSTER}`;
+  console.log(`  Explorer:  https://explorer.solana.com/address/${mintAddress}${explorerSuffix}`);
@@
-  console.log("  SOLANA_CLUSTER=devnet");
+  console.log(`  SOLANA_CLUSTER=${CLUSTER}`);

Also applies to: 87-89, 172-175

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@scripts/setup-mach-token.ts` around lines 52 - 65, Validate the
SOLANA_CLUSTER value and stop hardcoding "devnet" in outputs: add an explicit
whitelist check for CLUSTER (accept only "localnet", "devnet", "mainnet-beta")
and either default to "devnet" or throw a clear error if the env is invalid,
update getRpcUrl() to use the validated CLUSTER value, and replace any hardcoded
"devnet" strings in the user-facing explorer/.env output blocks (the sections
around lines 87-89 and 172-175) so they print the actual CLUSTER value rather
than always showing devnet; reference the CLUSTER constant and getRpcUrl when
adjusting those output generation sites.

.env.example (1)

164-164: Keep PORT aligned with API_PORT if it is an alias.

This line sets PORT=3000 while API_PORT is already 4000, which creates conflicting defaults for services that read different keys.

Proposed fix

-PORT=3000                            # API listen port (alias for API_PORT in some services)
+PORT=4000                            # API listen port (alias for API_PORT in some services)

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In @.env.example at line 164, PORT is currently set to 3000 but API_PORT is
4000, causing conflicting defaults; change the PORT default to match API_PORT
(set PORT=4000) or remove the duplicate and add a comment that PORT is an alias
of API_PORT so both keys stay consistent (update the PORT line and/or comment
referencing PORT and API_PORT).

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes